REMARKS 



The most recent office action has been carefully considered together with 
the present application and amendments have been made to claims 1, 39, 53 and 67. 
Claims 39 and 53 were only objected to, and have been amended to make them 
independent by incorporating the subject matter of claim 1 and all intervening claims. 

The examiner has modified the rejections of claims 1-27, 30-38 and 44-52 
and 57-70 as being unpatentable over Kardos et al. U.S. Patent No. 6,430,562 (hereinafter 
referred to as "Kardos") in view of Kisor et al, U.S. Patent No. 6,098,091, (hereinafter 
"Kisor") under 35 U.S.C. § 103 rather than the prior anticipation rejection based upon 
Kardos. 

It is strongly believed that amended claim 1 is neither taught nor suggested 
by Kardos, applied singularly or in combination with Kisor or any of the other references 
of record. Amended claim 1 is now directed to a system for managing the maintenance 
of building facilities, the system being of the type which utilizes predefined events to 
carry out managing operations for the building facilities and comprises, inter alia, at least 
one server adapted to receive predefined events including building inspection events 
from a client that can be located at the building facilities and forward said events to a 
clearinghouse via a communication link, in addition to the at least one client as claimed 
and the clearinghouse as claimed. 

The examiner has now recognized that Kardos is silent regarding 
authorizing predefined events that can be performed at each client based on the log-in 
identity of the client, but contends that Kisor applies this basic deficiency. Applicants 
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totally disagree. Kisor has absolutely nothing to do with a system for managing the 
maintenance of building facilities, has nothing to do with performing and reporting 
inspection events, certainly does not have anything to do with authorizing selected 
predefined events that can be performed by each client according to said log-in identity of 
each client in the context of the system as claimed. 

Kisor is directed to a method and system for assigning tasks to computers 
that are connected in a wide area network. Kisor schedules remote computers to do tasks 
and the essential operation of the Kisor system is believed to be set forth in column 4 5 
lines 37-50: 

The central computer 204 runs management 
program 144 which periodically polls remote systems 208 
regarding the time of day when the remote system will be 
available to operate in a contractor relationship and the 
resources available 224 on the remote system 208. This 
information is transmitted back by the remote system 208 
along the line 216 to the central computer 204. 

The central system 204 executes a management 
program 144 which includes a scheduler 228. The 
scheduler 228 organizes tasks 232 that need to be 
completed with the resources available information 224 
transmitted by the remote computer 208. The central 
computer then generates a schedule of tasks to be 
completed by the remote computers. 

Also, the Kisor abstract describes the operation of the system as scheduling 

of a large number of computers in a wide area network and determining whether a remote 

computer still subscribes to an Internet service provider and billing the remote computer 

accordingly. This is very different from the system claimed by applicants. Not only is it 

much different from applicants' system as claimed in amended claim 1, it is completely 
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unrelated to Kardos. So much so that the combination of Kisor and Kardos is believed to 
be an improper hindsight reconstruction using applicants claims as a roadmap. There is 
no motivation provided by either Kisor or Kardos to combine one with the other. 

Applicants' specification defines a client at page 3, line 12 as a computer 
which can be personal computers, other computers, mobile computing devices such as 
PDA's as well as cell phone devices and that any of these devices would be referred to 
simply as a client. That being the case, the recitation that the client has a unique login 
identity is something quite different from what is being described in Kardos at column 
16, lines 43-49. That text states only that the OSS server 132 generates a schedule that 
provides time available on a per skill basis. Similarly, on column 29, at lines 43-55, it 
demonstrates that the OSS server 132 merely book work orders against resources on a 
requested day for individuals that have the "preferred skill set". An override indicator 
can prevent an appointment from being booked for people in such a preferred skilled set. 
This is again repeated at column 30, lines 34-45 where it is discussed that a booking 
request can be rejected because there are not enough resources to work the order on a 
requested day. More particularly, the discussion includes "this approach of first sending 
the request without override and then resending it with override in the event the first 
attempts fails may be necessary to overcome a limitation in the OSS server 132 which 
can prevent the appointment from being booked against the preferred skill set when the 
override indicator is set." It is clear that Kardos is intending to manage the technicians 
that are working for the company for the purpose of completing work orders. 
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The examiner's reliance on column 19, lines 53-62 is also believed to be 
misplaced for the reason that all that is being accomplished as described is to send a 
message to an identified technician so that the identified technician can be dispatched to 
work on a work order. There is nothing in this portion of the specification to indicate that 
the technician is a client or that it has a unique login identity or that it is adapted to send 
anything, and particularly to selectively send said predefined events to said server via 
said communication link. There is nothing in any of this cited text that indicates that a 
clearinghouse is adapted to authorize selected predefined events that can be performed by 
each client according to said login identity of each such client, to selectively schedule 
events in response to data stored in said database and to monitor the status of all said 
predefined events stored in said database. The Kardos system simply does not operate in 
this manner and therefore cannot teach or suggest the system as claimed. 

There is simply no teaching or suggestion in Kardos that only certain, i.e., 
selected predefined events that are determined according to the login identity of the client 
are available to be performed by the client. This discerning selectivity that originates 
with a client is simply not functionality that is carried out by Kardos, either singularly or 
in combination with Kisor. 

The above arguments equally apply to amended method claim 67. Also, 
because the examiner has generally restated rejections from prior office actions, 
applicants repeat their previous arguments for patentability here for completeness. 

Claim 4 further defines the system wherein one or more of said server, 
clearing house and client includes means for defining various levels of authorization for 
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limiting access to predetermined events. Clearly, not only does Kardos not have the log- 
in identity as defined in claim 1, but totally fails to teach or suggest having various levels 
of authorization as is set forth in this claim. 

Claim 5 further defines the system wherein one or more of said server 
clearing house and client include predefined templates for selected events wherein said 
templates comprise a plurality of checklist items and possible responses to said checklist 
items. Nowhere in Kardos is there even a hint of the use of predefined templates for 
selected events wherein the templates comprise a plurality of checklist items and possible 
responses to those checklist items. Kardos simply is not designed to have this capability 
and therefore cannot teach or suggest this claim. 

Claim 6 further defines applicants' system wherein said predefined events 
include one or more events selected from the group consisting of 19 separate events 
which relate to notification events, tasks events, set up events, work requests and request 
processing events, as well as work order and work order processing events. Assuming 
for the sake of argument that Kardos teaches or suggests any of these events, it cannot be 
honestly concluded that only a few of the events are comparable to those 19 events that 
are set forth in claim 6. Kardos is not designed to operate in the manner described in this 
claim and certainly cannot teach or suggest a system having this functional capability. 

With regard to claim 7, it further defines a system as creating a notification 
event responsive to preselected ones of said predetermined events not having been 
completed as prescribed and are therefore overdue. The examiner admits that Kardos is 
silent regarding the functionality of this claim and cites Hull as supplying the deficiency 
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in an obviousness rejection. However, Hull fails to teach or suggest the subject matter of 
this claim because there is no notification event produced by Hull responsive to the event 
being overdue. The citation to column 12, line 65 to columns 13, line 10 which the 
examiner apparently relies on is totally misplaced. Hull merely contacts a designated 
person if the system cannot find utility rates in the context of a building management 
system. Additionally, Hull does not create a notification event responsive to preselected 
ones of said predetermined events not having been completed. 

With respect to claim 11, it claims a system wherein during preselected 
ones of said events an authorized client is adapted to add new data, edit existing data or 
exit said event. Kardos fails to teach or suggest this claim because it simply does not 
operate in the manner whereby an authorized client can add new data, edit existing data 
or exit the event. Claim 12 should be allowable for similar reasons. 

With respect to claim 13, it further defines the system wherein said 
clearinghouse selectively provides authorization to said client to request events in 
response to said client communicating its unique log-in identity to the server. Since the 
Kardos system is not concerned with authorization or unique log-in identities, it is 
incapable of teaching or suggesting the subject matter of this claim. 

Claim 14 is similarly incapable of being taught or suggested by Kardos for 
the reason that it does not have a download tasks event that can be requested after 
authorized communication is established. Moreover, claim 15 further defines additional 
functionality when during said download tasks event the authorized client downloads task 
list data from the clearinghouse and determines whether the data is valid and also 
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determines whether communication with said server is disconnected when the task list 
data is not valid. Kardos simply is incapable of teaching or suggesting the subject matter 
of this claim because Kardos simply does not operate in this manner. 

Claim 16 adds further functionality wherein during one of a download tasks 
event or an upload task event, said authorized client is adapted to make an entry into in an 
exception log when communication with said one server is disconnected. Kardos does 
not operate in this manner and the notion of an exception log is not mentioned anywhere 
in the Kardos patent. 

Claim 17 further defines the system of claim 16 wherein during one of said 
downloads tasks event or said upload task event, said authorized client is adapted to 
check communication for a predetermined maximum retry count when communication 
with the server is disconnected and make an entry an exception log once the 
predetermined maximum retry count has been tried. Kardos does not operate in this 
manner and is therefore incapable of teaching or suggesting the subject matter of this 
claim. 

Claims 18 and 19 define additional functionality during the download tasks 
event that is incapable of being performed by Kardos and is not taught or suggested by 
Kardos. 

Claim 23 further defines the system wherein during said performed task 
event said clearinghouse is adapted to forward checklist item data for said task to said 
server. Claim 24 further defines the system wherein during said performed task event 
said server is adapted to send said checklist item data to said authorized client and claim 
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25 further defines a system wherein during said performed task event, said authorized 
client is adapted to display a list of the checklist items from the checklist item data for 
completing said checklist items. Kardos simply does not operate in this manner because 
it does not utilize checklists in the manner as claimed. Further, claim 26 defines a system 
wherein during said performed task event, said authorized client is adapted to respond, 
skip or stop said checklist item from said checklist item data until all checklist items have 
been completed. This claim is not taught or suggested by Kardos because it does not 
operate in a manner which utilizes checklists and certainly does not facilitate the 
functionality whereby the authorized client can respond, skip or stop each checklist item 
from the data as claimed. 

Claim 27 further defines the system wherein during said performed task 
event, said authorized client is adapted to exit the display as claimed, store response data 
for said checklist item when the client elects to respond to the same and respond, skip or 
stop the next item from the checklist item data when said authorized client elects to skip 
said first checklist item. Clearly Kardos does not utilize checklist items in the manner as 
set forth in this claim and therefore cannot teach or suggest it. 

Claim 30 further defines a system wherein performance rating type set-up 
event allows said authorized server to display an option menu for yes/no type, multiple 
options type and numerical type performance rating to said authorized client for 
selection. There is no inspection carried out by Kardos, Kisor or Hull and therefore this 
claim cannot be taught or suggested by these patents. Moreover, since they do not do 
inspections and are not concerned with any performance rating, they clearly do not have 
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the capability of displaying an option menu for the various types of performance rating 
that are set forth in this claim. 

Since they do not perform the performance rating type set-up event, neither 
of these references can teach or suggest the subject matter of claim 31 which saves the 
performance rating type data onto said database. Further, claim 32 cannot be taught or 
suggested by Hull or Kardos for the reason that they simply do not define tolerance levels 
to create a special action event for performance rating data stored in the database. Kardos 
and Hull cannot teach or suggest this claim because neither is designed to carry out 
inspections at all, much less carrying out a performance rating or define a tolerance level 
to create a special action event based on performance rating type data. 

Claim 33 is not taught or suggested for the simple reason that neither 
Kardos, Kisor nor Hull teach or suggest inspection functionality and particularly the 
functionality of an authorized client inputting and editing inspection templates data for a 
specific jobsite. They simply do not have this functionality. Similarly, claim 34 cannot 
be taught or suggested by Kardos, Kisor or Hull because they are not concerned with 
inspection templates data, much less inspection steps that are carried out according to a 
default checklist item data or a user defined checklist item data stored in said database. 
The words "inspect" or "inspection" do not appear anywhere in either the Kardos, Kisor 
or Hull patents. 

Claim 35 further defines the system wherein said clearinghouse is adapted 
to respond to inspection data sent from an authorized client during an inspection 
processing event and determine whether the inspection data from said authorized client 
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are valid. Not only are Kardos, Kisor and Hull not concerned with inspection capability, 
neither patent discusses determining whether received inspection data is valid. The only 
checking that appears to be done by Kardos is to determine whether messages were 
received, which is completely different from what is claimed. 

Claim 36 further defines the system wherein during said inspection 
processing event the clearinghouse is adapted to make an entry in an exception log when 
said inspection data is not valid and is not taught or suggested by Hull, Kisor or Kardos, 
applied singularly or in combination for the same reasons set forth with regard to claim 
35. 

Claims 37, 38 and 39 are not taught or suggested by Kardos, Kisor or Hull, 
applied singularly or in combination for the same reasons that were set forth with regard 
to claims 30, 31 and 32 relating to tolerance levels. 

Claim 46 further defines the system wherein during said work request 
processing event, said authorized client is adapted to enter an approval code when said 
authorized client accepts a selected open work request from said list. The notion of a 
client entering an approval code when said authorized client accepts a selected open work 
request is simply not a capability that is discussed, inferred or suggested by Kardos. 
Approval in this context or any context is not even mentioned in the Kardos patent. For 
similar reasons, claims 47 and 48 are not taught or suggested by Kardos. 

With regard to claim 49, it defines a system wherein during said work 
request processing event, said authorized client is adapted to enter an explanation for said 
selected work request data when said authorized client rejects a selected open work 
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request data stored in said database. Kardos does not teach or suggest the functionality of 
the authorized client rejecting a selected open work request data. Any rejection of a work 
request in Kardos is done at the server level, i.e. 5 there aren't enough resources in the 
workforce to carry out some requested work. This is a very different functionality. The 
notion of a client rejecting a work request is simply not contemplated or discussed in 
Kardos. 

Claim 68 is directed to a method for managing operational facilities using 
predefined events to carry out managing operations for the facilities as claimed and 
includes the step of selectively authorizing, by the clearinghouse, said events from each 
client according to said log-in identity of each such client among the other steps as set 
forth in the claim. Because Kardos does not selectively authorize events according to the 
log-in identity of each client, it certainly fails to teach or suggest this claim. The 
arguments that are set forth with regard to claim 1 above also apply here. Claim 70 is 
also believed to be allowable for the same reasons that were advanced with regard to 
claim 1. 

With regard to the dependent claims that were not specifically discussed 
herein, these claims depend from one or more other claims and necessarily include the 
subject matter of those one or more claims in addition to reciting further structure and/or 
functionality not found in those claims. Because of these reasons, it is also believed that 
these dependent claims are allowable. 
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For these reasons, applicants respectfully request reconsideration and 



allowance of all claims presenting pending in the application. 
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